The IMS is a standardised next generation network (NGN) architecture for network operators providing mobile and fixed multi-media services. It uses a 3rd Generation Partnership Project (3GPP) standardised implementation of SIP and runs over the standard Internet protocol (IP). Existing telephone systems (both packet-switched and circuit-switched) are supported also. IMS uses open standard IP protocols as defined by the Internet Engineering Task Force (IETF). In this way, a multimedia session for example between two IMS users, between an IMS user and a user on the Internet, or between two users on the Internet can be established using exactly the same protocols. IMS merges the Internet and the cellular worlds by using cellular technologies to provide ubiquitous access and Internet technologies to provide appealing services.
The IMS comprises three main components: the serving call session control function (S-CSCF) on a control layer, and the home subscriber server (HSS) as well as a session initiation protocol (SIP) application server (AS) on an application layer.
The SIP protocol is a core control technology of IMS. It is used for controlling multimedia sessions combining for example voice and data streams. Essentially, SIP is a text-based protocol for communication sessions between parties. In particular, SIP is used for the establishment, control and finalization of communication sessions between network-based applications and also for the control of media channels between those applications. After a session is established, other protocols can be used for communication between applications. Thus, the major functions of SIP are session control, addressing and mobility management on service level.
IMS provides a lot of common functions used by mobile networks, such as AAA (authentication, authorization, and accounting), charging, access control, and HSS (i.e. user profile databases). These functions of IMS are meant to be used by the converged applications in a uniform way, so that there is no need to have separate mechanisms applied for example to voice and to data communications.
In parallel to the IMS domain, the extensible Markup Language (XML) Web Services (WS) concept has been developed. XML WS are a relatively new technology for the creation of distributed, highly interoperable systems. XML WS are based on XML-based standards, like Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL) and Universal Description, Discovery and Integration (UDDI). Web Services are cross-platform interoperable, and programming language independent. They have become a popular means of development and system integration of enterprise systems and network applications. Due to their flexibility and a design that is more aligned with IT networks, Web Services based architectures, e.g. Service Oriented Architectures (SOAs), are emerging quickly and are likely to be adopted in mobile communication network design.
Most Web Services are stateless, which means that each invocation of the Web Service should contain all the information it needs to process a request, since the processing depends only on this data. This design greatly simplifies implementation of WS. Recently, however, many researchers and practitioners in the WS area have realized that there is also a need for stateful Web Services. Such stateful services are particularly important for transactions involving several service invocations. They are equally important where a correlation between messages is required, e.g. electronic banking, and booking of tickets. Several WS specifications that address these issues, e.g. WS-Context, WS-Addressing and WS-Resource Framework, have been submitted to standardization, but most of these simply complement WS SOAP invocation headers through session information headers.
The IMS architecture defines that all incoming service invocations be carried out over SIP sessions. The IMS nodes, e.g. CSCF-I and the CSCF-P, are SIP servers that handle incoming SIP messages. However, even today many non-SIP based services exist in the operator domain and these services often use non-SIP protocols and technologies (e.g. Web Services, but also J2EE, NET, etc.).
Providing access for external users to services, in particular non-SIP services, in the IMS domain is generally not possible because external third-party non-SIP service consumer applications are typically unaware of the fact that the invoked service is located inside the IMS domain, and such external consumer applications typically do not support SIP. Hence, a non-SIP service consumer is unable to access the service in question inside the IMS domain, which greatly reduces the availability and therefore the value of the service.
SIP and WS address similar problems, but each has its own solutions to session management. In other words, the approaches used for session management by SIP and WS are independent from each other. As a result, Web Services deployed inside the IMS domain require their own IMS-incompatible WS infrastructure, including authentication, accounting, charging and other IMS functionality. Further, WS invocations are executed based on URLs (unique resource locators) that require a precise knowledge of the service's current network address (e.g. IP number, DNS name, etc.). This means that users cannot invoke services hosted on mobile platforms (e.g. mobile terminals, and network nodes that regularly change their URL) until their current URL is known.
However, Web Service SOAP invocation headers are complemented through session information headers. This can lead to large SOAP messages compared to the size of the payload. Such headers are sent with each SOAP message and thus consume more bandwidth than session-less Web Services. Increased traffic can be a special issue in the over-the-air mobile environments, where it could introduce a higher network load and lead to bigger latencies. While compression schemes to compress and decompress SOAP messages may be employed to address this issue, these have been shown to be very resource intensive and time consuming, even with high-end mobile terminals.
Accordingly, there is a need for a technique for providing increased interoperability between services located within the IMS domain and client components situated outside the IMS domain.